Bootstrapping the Web
Part 1: On Issues Regarding the Use of Namespaces of Identifiers in Network-Based Applications
Part 2: A Proposal for Representing Resource Identifiers in the OpenURL Framework on the Web
Tony Hammond
Elsevier Ltd, Advanced Technology Group,
32 Jamestown Road, London, NW1 7BY, UK
Herbert Van de Sompel
Los Alamos National Laboratory, Research Library, MS-P362, PO Box 1663, Los Alamos, NM 87545-1362, USA
Disclaimer - The views and opinions of the authors of this paper do not necessarily state or reflect those of their respective organizations. |
Part 1: On Issues Regarding the Use of Namespaces of Identifiers in Network-Based Applications
In the conclusion of the third D-Lib Magazine paper on the SFX research on context-sensitive linking [1] the authors wrote:
‘Also, a standardization of a local redirection URL – like the SFX-URL – and of vendorId, databaseId and nameSpace values is required. Such a standardization will also be valuable for other ongoing work in the digital library environment.’
The above-mentioned SFX-URL became ‘de-facto standardized’ through the publication in 2000 of the draft OpenURL (now referred to as OpenURL 0.1) [2], and its fast acceptance in the scholarly information industry. NISO Committee AX recently released a two-part document entitled ‘The OpenURL Framework for Context-Sensitive Services’ [3] that defines core components required to allow the implementation of context-sensitive service-environments in the scholarly information Community, as well as in potentially any other network-based information Community. Amongst other things, the document addresses, in a general manner, the elements that require standardization as per the above quote.
Of special importance is the issue referred to as ‘nameSpace values’, which is about the identification of resources in the OpenURL Framework by means of Identifiers in Namespaces. OpenURL 0.1 hardwired some Namespaces that are important for the scholarly information Community – ‘bibcode’, ‘doi’, ‘oai’, ‘pmid’ – into the specification. It is interesting to note that none of the above-mentioned Namespaces have an official status in the Internet infrastructure, that is, they are not registered as URI Schemes or as URN Namespaces. Yet they are commonly used in networked scholarly information applications. Also interesting to note is that some of the above-mentioned Namespaces are well-specified in dedicated documents created for public use, while the specification of others may be embedded in descriptions of broader information systems, or may not necessarily be easy to discover, or may even not exist. For example, it seems that no public specification of the ‘pmid’ Namespace of PubMed Identifiers exists – yet that Namespace forms the basis of many networked applications.
When generalizing the OpenURL Framework beyond the scholarly information environment, NISO AX recognized that hardwiring Namespaces into a specification was not a viable option. Therefore, it introduced the notion of a Registry that – amongst others – lists Namespaces that can be used to identify resources in OpenURL Framework–based context-sensitive service environments. NISO AX also recognized that the aforementioned existence of popular Namespaces without legitimate status in the Internet infrastructure, or without rigorous definitions, is not exclusive to the scholarly information environment. For example, Vehicle Identification Numbers (VIN) are commonly used in network-applications in the US-based car-selling Community, yet there exists no VIN URI Scheme or URN Namespace. US ZIP codes, and D&N DUNS numbers (EDI applications) are other examples given in the Bison-Futé paper [4] that provided inspiration for the work of NISO AX. Many other such Namespaces exist.
As a result of the above considerations, NISO AX introduced the concept of Naming Environments, to facilitate the usage of different types of Namespaces in the context of OpenURL Framework applications. A Naming Environment bundles Namespaces of the same type. It can be considered to be a ‘namespace of namespaces’. The OpenURL Framework documents recognize three such Naming Environments:
· The URI Naming Environment This Naming Environment encompasses all Namespaces listed in the IANA Registries for URI Schemes, including the Registry for URN Namespaces. As a result of the introduction of this Naming Environment, the OpenURL Framework allows for the identification of resources by means of URIs or URNs. For example, in OpenURL Framework applications, ‘uri:mailto:herbertv@lanl.gov’ is an Identifier in the URI Naming Environment that uses the ‘mailto’ URI Scheme.
· The ORI Naming Environment This Naming Environment encompasses Namespaces that are registered by (or on behalf of) information Communities in the OpenURL Registry. The registration mechanism is intended to be lightweight, allowing for a fast track mechanism to facilitate the use of popular/public Namespaces in OpenURL Framework applications. As a result of the introduction of this Naming Environment, the OpenURL Framework allows for the identification of resources by means of registered ORI Namespaces. For example, in OpenURL Framework applications, ‘ori:uszip:87501’ could be an Identifier in the ORI Naming Environment that builds on the (fictionally) registered ‘uszip’ Identifier Scheme.
· The XRI Naming Environment This Naming Environment is introduced to facilitate the usage of private Namespaces, for which no need for public recognition exists. Typically, this Naming Environment will be used to identify resources in ‘local’ applications, or in applications that include parties that operate on the basis of prior, not publicly disclosed agreements. For example, ‘xri:ASIN:83920393’ could be an Identifier in the XRI Naming Environment used by Amazon.com in communications between internal systems.
The introductory quote from 1999 suggested that the standardization of ‘nameSpace values’ could be valuable for other ongoing work in the digital library environment. Likewise, today it is felt that the Naming Environment concept, and especially the introduction of a low-barrier mechanism to facilitate the registration of public Namespaces, may be valuable well beyond OpenURL Framework applications, and might provide a generic mechanism to bootstrap popular Namespaces for use in web-based services.
Not surprisingly, the release for Public Comment of the OpenURL Framework documents immediately led to comments from interested parties as to why does the OpenURL Framework not make use of URI schemes, and – on a related vein – why do its Naming Environments conflict with potential URI schemes.
The first of these comments is the more substantial. As has been noted above the OpenURL Framework has adopted an independent system of tiered Naming Environments – URI/ORI/XRI – which allows for a comprehensive treatment of all Identifiers. The OpenURL Framework Naming Environments are orthogonal to the Internet URI Schemes and remain independent of any current or future assignations under that domain. They provide an immediate and coherent solution to the problem of referencing resources in a networked environment
This first public comment proffered as a solution that the OpenURL Framework register either a new URI scheme for the ORI Naming Environment or a new URN Namespace ID, and make use of the reserved experimental URI Scheme prefix (‘x-’) for the XRI Naming Environment, while representing the URI Naming Environment names natively as URIs. In other words, a hybrid solution. At first glance this may appear reasonable but in fact it is riddled with difficulties. Registering a new URI Scheme/URN Namespace ID is by no means a guaranteed process. As an illustrative example, the DOI Community have been endeavoring to register ‘doi’ as a URI Scheme for some 12 months now and have already issued two Internet Drafts – a third is now being issued. This Community has an installed base of over 7 million identifiers deployed but with (as yet) no official Internet recognition. Another URI Scheme in the wings is the ‘tag’ proposal which has now been 24 months in review. Obviously, to wait for a period of months or even years to complete such a registration process before the OpenURL Framework can be out to Trial Use is untenable.
Another suggestion was made that a URN Namespace ID registration could be a more straightforward process, but here again there are difficulties. URN has the intent that the Identifiers will be persistent. This may not be something that the OpenURL Framework would want to guarantee for Namespaces subsumed under the ORI Naming Environment. The problem is that registered Namespaces are third party Namespaces and OpenURL Framework Communities – as registration agents – are not in a position to determine the intent of those Namespaces. There may also be expectations of resolution behavior for URNs – again something that the OpenURL Framework would not be in a position to guarantee.
As to the idea of using the reserved experimental URI Scheme prefix (‘x-’) for the XRI Naming Environment, again there is a problem of intent. Names under the XRI Naming Environment are not (necessarily) experimental in any way, but instead are specific to the Referrer environment. There is also no guarantee of uniqueness as there is no assigned naming authority for such URI Schemes. And lastly there is some confusion between the naming practice for URI alternative trees – RFC 2717 uses a hyphen to delimit the prefix, while a later W3C Note (21-9-2001) uses a period. Further, this W3C Note goes on to say that no alternative trees have been registered to date, although RFC 1738 does indeed reserve the set of trees beginning with ‘x-’ for experimental use.
The other major public comment received mentioned a conflict of interest between work currently going on in the Oasis TC on XRI and the use of XRI in the OpenURL Framework. In fact there is no conflict because – as stated above – the OpenURL Framework Naming Environments are orthogonal to the URI Schemes and operate within their own context, and so can never collide with them. This could be made immediately obvious by the simple device of rooting the OpenURL Framework Namespaces – by preceding each with a colon, e.g. ‘:xri:’, the Namespaces cannot be mistaken for URI Schemes which strangely remain unrooted.
It is recommended that a small group of experts assembled by NISO consider along with representatives from the IETF and W3C Communities how best to integrate the OpenURL Framework Naming Environments with the URI system. There are several factors that need to be considered: choice of URI scheme(s), transform methodologies, character encodings, naming authorities, and dereference expectations, to mention but a few. A successful outcome from this endeavor would lead to nothing more than a general means to bootstrap common namespaces onto the public Internet.
References
[1] Van de Sompel, Herbert and Patrick Hochstenbach. Reference Linking in a Hybrid Libary Environment, Part 3: Generalizing the SFX solution in the ‘SFX@Ghent & SFX@LANL’ experiment. 1999. D-Lib Magazine. <http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html>
[2] The OpenURL, v.0.1. Editors: Herbert Van de Sompel, Patrick Hochstenbach and Oren Beit-Arie. 2000. <http://www.sfxit.com/openurl/openurl.html>
[3] The OpenURL Framework for Context-Sensitive Services. NISO AX. <http://library.caltech.edu/openurl/Public_Comments.htm>
[4] Van de Sompel, Herbert and Beit-Arie, Oren. Generalizing the OpenURL Framework beyond References to Scholarly Works: the Bison-Futé model. 2001. D-Lib Magazine. <http://www.dlib.org/dlib/july01/vandesompel/07vandesompel.html>
Part 2: A Proposal for Representing Resource Identifiers in the OpenURL Framework on the Web
Review of OpenURL Framework Naming Environments
To allow the extensible description of OpenURL Framework ContextObject Entities by means of Identifiers, the concept of a Naming Environment is introduced. A Naming Environment is simply a namespace of namespaces of Identifiers. The OpenURL Framework introduces a tiered Naming Environment system – URI, ORI, XRI – each serving a specific purpose. We can characterize these use cases as: church, street, home.
The URI Naming Environment reflects the broad church of URI adherents who believe in having a uniform naming scheme across the Web. This common approach is obviously key to establishing a general naming interoperability and is strongly advocated by the W3C.
However, out on the streeets, there are multiple other information identifier schemes in common use which are not represented under URI schemes. The ORI Naming Environment reflects the reality that online communities often trade in specific identifier schemes known across industry verticals.
But this is still not enough. Other ‘local’ identifier schemes are spoken at home and may be shared in restricted B2B or B2C contexts. This is the domain of the XRI Naming Environment.
The OpenURL Framework naming practice offers an immediate and coherent pragmatic solution to referencing resources in a networked environment. The naming system is self-contained and is best regarded as being orthogonal to the Web (defined here as the set of all URIs). By mapping OpenURL Framework resource identifiers onto URIs we have a general bootstrapping mechanism to promote namespaces onto the Web.
In Church – The Uniform Resource Identifier (URI) Naming Environment
The Uniform Resource Identifier (URI) Naming Environment contains all URI schemes registered with IANAhttp://www.iana.org/assignments/uri-schemes including the registered URN Namespace Identifiers.
Registries on which the URI Naming Environment is based:
· IANA URI scheme registry:
http://www.iana.org/assignments/uri-schemes
· IANA URN Namespace Identifiers:
http://www.iana.org/assignments/urn-namespaces
These registries are an essential part of the Internet infrastructure. Therefore, Identifiers in the URI Naming Environment are globally understood.
Within the OpenURL Framework naming system Identifier Namespaces from this Naming Environment are referenced by means of the URI Namespace ‘uri’, which qualifies an Identifier from a URI scheme namespace.
· uri:urn:ISBN:0262011808
· uri:mailto:jane.doe@caltech.edu
· uri:http://www.sciencedirect.com
On the Street – The Open Resource Identifier (ORI) Naming Environment
Many commonly used, community-specific schemes for the identification of resources are not part of the Internet infrastructure. To support such schemes the OpenURL Framework creates a Registry for namespace identifiers. The Open Resource Identifier (ORI) Naming Environment contains namespaces that are registered in the Registry for namespace identifiers.
Registry on which the ORI Naming Environment is based:
· The OpenURL registry:
http://openurl.info/registry/
This Registry is public. Therefore, Identifiers in the ORI Naming Environment are globally understood.
Identifier namespaces from this Naming Environment are referenced by means of the ORI Namespace ‘ori’, which qualifies an Identifier from a registered namespace.
· ori:pmid:9036860
· ori:doi:10.1126/science.275.5304.1320
· ori:rfr:oclc.org:Inspec
At Home – The Private Resource Identifier (XRI) Naming Environment
Some identifier schemes are specific to a given information resource; there may be no need for them to be understood globally. The Private Resource Identifier (XRI) Naming Environment contains namespaces that are specific to Referrer environments.
There are no global mechanisms available that facilitate interpreting an Identifier namespace from this Naming Environment, as opposed to the URI and ORI Naming Environments. Without such global mechanisms, interpretation of an identifier in the XRI Naming Environment by the Resolver most likely requires a prior understanding between the Referrer and the Resolver.
Identifiers under this Naming Environment are referenced by means of the XRI Namespace ‘xri’, which qualifies an Identifier from a Referrer-specific namespace.
· xri:my-service:addToCart
· xri:ERL:MX01:123059849
Syntax
The general syntax of OpenURL Framework resource identifiers is that of a hierarchical colon-delimited string. The topmost (i.e. leftmost) component is ‘uri’ for URI Naming Environment, ‘ori’ for ORI Naming Environment, and ‘xri’ for XRI Naming Environment.
Proposal – Examples
We shall consider the following application Identifiers from each of the three OpenURL Framework Naming Environments for the sake of example:
· uri:http://www.example.org/abcde
· ori:pmid:9036860
· xri:my-service:addToCart
We shall also consider an example of a registered ORI Identifier which shows an extended hierarchy:
· ori:fmt:xml:xsd:book
Proposal – Methods
Currently, as of March 2003 there are some 38 registered URI schemes under IANA and 3 reserved schemes. Not all schemes are equally valid being bound to specific protocols (sometimes moribund) or having a specific intent.
There are two main approaches: We either wrap OpenURL Framework resource identifiers under a single URI scheme – this is the case for ORI/XRI identifiers and may also be done for URI identifiers when a common handling is desired. The other approach is to promote OpenURL Framework resource identifiers to multiple URI schemes – a hybrid method.
This leads to 7 candidate methods for mapping OpenURL Framework resource identifiers onto URIs proceeding from esatblished URI schemes first:
· Method 1 –‘http:’
· Method 2 –‘data:’
· Method 3 –‘tag:’
· Method 4 –‘x-open:’ *
· Method 5 –‘open:’ *
· Method 6 –‘urn:open:’ *
· Method 7 –Hybrid
* The term ‘open’ is just a working term.
Method 1 – Use of the ‘http:’ URI scheme
Status – RFC 2616
The most obvious way to present OpenURL Framework resource identifiers as URIs is to make them available under the mother of all URI schemes – the ‘http:’ scheme. This can be done by representing URI and ORI identifiers under the OpenURL domain (‘openurl.info’) and XRI identifiers either under the OpenURL domain, or under the OpenURL domain and introduce a Referrer-specific qualification.
We can either treat the identifiers as opaque strings or reflect the natural hierarchy of an ‘http’-based URI.
As opaque strings, the URI and ORI identifiers could be presented as
· http://openurl.info/uri/uri:http://www.example.org/abcde
· http://openurl.info/ori/ori:pmid:9036860
· http://openurl.info/ori/ori:fmt:xml:xsd:book
while an XRI identifier could be presented variously as
· http://openurl.info/xri/xri:my-service:addToCart
· http://openurl.info/xri/xri:my-service:addToCart@example.com
Note that in the first case, there is no authority component and thus no guarantee of uniqueness, whereas in the second case an authority component is used to qualify the XRI identifier (here using a mail address like syntax) and thus there is no collision between Identifiers from different Referrer environments. We also suggest to locate the identifiers under the relative URI paths ‘/uri’, ‘/ori’ and ‘/xri’ in order to better manage the domain.
As hierarchical strings, the URI and ORI identifiers could be presented as
· http://openurl.info/uri/http///www.example.org/abcde
· http://openurl.info/ori/pmid/9036860
· http://openurl.info/ori/fmt/xml/xsd/book
while an XRI identifier could be presented variously as
· http://openurl.info/xri/my-service:addToCart
· http://openurl.info/xri/my-service:addToCart@example.com
In this case, there is no need to introduce relative URI paths as the mapping naturally provides such paths.
Note that URI identifiers can also be expressed natively as a URI by simply removing the URI Naming Environment prefix ‘uri:’:
· http://www.example.org/abcde
Pros:
The main advantage of using the ‘http’ URI scheme is its widespread familiarity and the general level of support – i.e. dereference capabilities – by Internet software components. Also use of the OpenURL domain (‘openurl.info’) provides a single authority component for all the OpenURL Framework resource identifiers.
Cons:
A disadvantage of presenting OpenURL Framework resource identifiers as ‘http’ URIs is the general expectation that ‘http’ URIs are derefenceable, which may not be the case here. One device for making such identifiers dereferenceable would be to establish service components located at the relative URI paths ‘/uri’, ‘/ori’ and ‘/xri’ which could return meaningful representations based on the subsequent path available from the <pathinfo> environment variable. (This is also another reason to locate the opaque identifier strings under relative URI paths.)
It must also be pointed out that the ‘http’ URI scheme is intended for documents which are retrieved using the HTTP network protocol. This may not apply to OpenURL Framework resource identifiers.
Method 2 – Use of the ‘data:’ URI scheme
Status – RFC 2397
Another method to presenting OpenURL Framework Identifiers as URIs is to make them available under the ‘data’ immediate addressing URI scheme. The ‘data’ URI scheme allows an arbitrary text representation to be presented within a URI. The URI syntax is
data:[<mediatype>][;base64],<data>
where the ‘<mediatype>’ defaults to ‘plain/text’. Since we are only concerned with plain text we omit the optional parameters and can present the OpenURL Framework resource identifiers as URIs by treating them as opaque strings and prepending the ‘data:’ URI scheme as follows:
· data:,uri:http://www.example.org/abcde
· data:,ori:pmid:9036860
· data:,ori:fmt:xml:xsd:book
· data:,xri:my-service:addToCart
Note that URI identifiers can also be expressed natively as a URI by simply removing the URI Naming Environment prefix ‘uri:’:
· http://www.example.org/abcde
Pros:
The advantage of using the ‘data’ URI scheme is that we present the OpenURL identifiers as simple data strings and make no attempt to interpret them within the URI context. A further advantage is that we do not require any authority component, eg a DNS name.
Cons:
A disadvantage of using the ‘data’ URI scheme is its relative unfamiliarity. A further disadvantage is that we do not require any authority component, eg a DNS name.
Another disadvantage is the relative unfamiliarity of the ‘data’ URI scheme and the fact that there are no dereference capabilities available
Method 3 – Use of the ‘tag:’ URI scheme
Status – Internet Draft: draft-kindberg-tag-uri-04.txt (Expired)
An alternative way to present OpenURL Framework resource identifiers as URIs is to make them available under the proposed ‘tag’ URI scheme. The ‘tag’ URI scheme allows us to present identifiers within a URI that are globally unique across space and time. The URI syntax is
tag:<authorityName>,<date>:[<specific>]
where ‘<authorityName>’ is either the DNS name or email address of the authority, and ‘<date>’ is the date. By using the canonical DNS name ‘openurl.info’ for the ‘<authorityName>’, the current year as ‘<date>’, we can present the OpenURL Framework resource identifiers as URIs by treating them as opaque strings and prepending the ‘tag’ URI scheme as follows:
· tag:openurl.info,2003:uri:http://www.example.org/abcde
· tag:openurl.info,2003:ori:pmid:9036860
· tag:openurl.info,2003:ori:fmt:xml:xsd:book
· tag:openurl.info,2003:xri:my-service:addToCart
The URI identifier can be expressed natively as a URI by removing the URI Naming Environment prefix ‘uri:’:
· http://www.example.org/abcde
Pros:
The advantage of using the ‘tag’ URI scheme is that we present the OpenURL resource identifiers as simple data strings under an authority component comprising a DNS name and a date pair.
Cons:
The main disadvantage of using the ‘tag’ URI scheme is the fact that its current status is unclear after passing through four Internet Drafts (24 months), the last having just expired on March 1, 2003. At this time it cannot be recognized as a valid URI scheme. Another disadvantage is its relative unfamiliarity and the fact that there are no dereference capabilities available.
Method 4 – Use of the reserved ‘x-open:’ URI schemes
Status – RFC 1738
RFC 1738 reserves URI schemes beginning with ‘x-’ for experimental use. This presents another straightforward way to present OpenURL Framework Identifiers as URIs by using a reserved URI scheme, ‘x-open’ say:
x-open:<?ri-id>
where ‘<?ri-id>’ is the OpenURL Framework resource identifier appended as an opaque string. By simply prepending the reserved ‘x-open’ URI scheme, we can present the OpenURL Framework resource identifiers as follows:
· x-open:uri:http://www.example.org/abcde
· x-open:ori:pmid:9036860
· x-open:ori:fmt:xml:xsd:book
· x-open:xri:my-service:addToCart
The URI identifier can be expressed natively as a URI by removing the URI Naming Environment prefix ‘uri:’:
· http://www.example.org/abcde
Pros:
The main advantage of using the ‘x-open’ URI scheme is that we can immediately present the OpenURL Framework resource identifiers as simple data strings. There is no need for URI scheme registration and no confusion with transport protocol.
Cons:
The disadvantage of using the ‘x-open’ URI scheme is that there is no naming authority and thus no guarantee that the URIs so minted will remain unique. Further while no transport protocol is implied by the ‘x-open’ URI scheme, there is still the intent that these are for experimental use which does not accord with the general intent of the OpenURL Framework resource identifiers.
There is also some confusion between the naming practice for URI alternative trees – RFC 2717 uses a hyphen to delimit the prefix, while a later W3C Note (21-9-2001) uses a period. Further, this W3C Note goes on to say that no alternative trees have been registered to date, although RFC 1738 does indeed reserve the set of trees beginning with ‘x-’ for experimental use.
Another disadvantage is the relative unfamiliarity of ‘x-’ URI schemes and the fact that there are no dereference capabilities available.
Method 5 – Use of a dedicated ‘open:’ URI scheme
Status – None at this time
A practical way to present OpenURL Framework resource identifiers as URIs is to make them available under a dedicated URI scheme, ‘open’ say. The ‘open’ URI scheme would have the following syntax:
open:<?ri-id>
where ‘<?ri-id>’ is the OpenURL Framework resource identifier appended as an opaque string. By simply prepending the ‘open’ URI scheme, we can present the OpenURL Framework resource identifiers as follows:
· open:uri:http://www.example.org/abcde
· open:ori:pmid:9036860
· open:ori:fmt:xml:xsd:book
· open:xri:my-service:addToCart
The URI identifier can be expressed natively as a URI by removing the URI Naming Environment prefix ‘uri:’:
· http://www.example.org/abcde
Pros:
The advantage of using the ‘open’ URI scheme is that we present the OpenURL Framework Identifiers as simple data strings under a dedicated URI scheme which serves as an authority component.
Cons:
The disadvantage of using a dedicated ‘open’ URI scheme is that the whole process of registering a new RFC would have to be started up by submitting an Internet Draft. There is no notion of how long this process would take and no guarantees at all that it would be approved by the IESG and so at this time such a dedicated scheme cannot be recognized as a valid URI scheme. (Note that the proposed ‘doi’ URI scheme is still awaiting approval 12 months after originally being submitted – although lately we hear encouraging signals that there may be some movement in the near future, and the proposed ‘tag’ URI scheme has been awaiting approval for 24 months – the last version just expired March 1, 2003.)
Method 6 – Use of a dedicated ‘open:’ URN Namespace ID under the ‘urn:’ URI scheme
Status – None at this time
A straightforward way to present OpenURL Framework resource identifiers as URIs is to make them available under a dedicated URN Namespace ID, ‘open’ say, under the ‘urn’ URI scheme. The ‘open’ URI scheme would have the following syntax:
urn:open:<?ri-id>
where ‘<?ri-id>’ is the OpenURL Framework resource identifier appended as an opaque string. By simply prepending the ‘open’ URI scheme, we can present the ORI/XRI identifiers as follows:
· urn:open:uri:http://www.example.org/abcde
· urn:open:ori:pmid:9036860
· urn:open:ori:fmt:xml:xsd:book
· urn:open:xri:my-service:addToCart
The URI identifier can be expressed natively as a URI by removing the URI Naming Environment prefix ‘uri:’:
· http://www.example.org/abcde
Pros:
The advantage of using the ‘open’ URN Namepsace ID is that we present the OpenURL Framework Identifiers as simple data strings under a dedicated URN Namespace ID which serves as an authority component.
Cons:
The disadvantage of using a dedicated ‘open’ URN Namespace ID is that the whole process of registering a new RFC would have to be started up by submitting an Internet Draft. There is no notion of how long this process would take if a formal URN Namespace ID were requested and no guarantees at all that it would be approved by the IESG and so at this time such a dedicated scheme cannot be recognized as a valid URN Namespace ID.
Another disadvantage is that URN has the intent that the Identifiers will be persistent. This may not be something that the OpenURL Framework would want to guarantee for Namespaces subsumed under the ORI Naming Environment. The problem is that registered Namespaces are third party Namespaces and OpenURL Framework Communities – as registration agents – are not in a position to determine the intent of those Namespaces. There may also be expectations of resolution behavior for URNs – again something that the OpenURL Framework would not be in a position to guarantee.
Also URN has a specific requirement for enabliing location independent identification of a resource. Again this cannot be assumed to be true for all OpenURL Framework resource identifiers. A case in point is the Handle System (‘ori:hdl:’) where a given handle defines a location within the global handle space, i.e. the Handle naming authority is directly equivalent to a DNS name.
Method 7 – Use of a hybrid mapping
Status – Mixed
From a URI perspective the OpenURL Framework resource identifiers could be accomodated as URIs by adopting a hybrid approach. For example, the following choices could be made – other choices may be possible.
URI resource dentifiers could be expressed natively as a URI by removing the URI Naming Environment prefix ‘uri:’:
· http://www.example.org/abcde
ORI resource identifiers could be expressed by registering a new URI scheme or a registering a new URN Namespace ID:
· open:ori:pmid:9036860
· open:ori:fmt:xml:xsd:book
· urn:open:ori:pmid:9036860
· urn:open:ori:fmt:xml:xsd:book
XRI resource identifiers could be represented under an experimental URI scheme:
· x-open:xri:my-service:addToCart
Pros:
The advantage of using a hybrid approach is that we reaffirm the primacy of the URI schemes and seek to minimize disruptions to existing scheme registrations.
Cons:
The disadvantage of using a hybrid approach is that we deny the unity of the OpenURL Framework Naming Environments and we lose the identity of representing those Naming Environments as URIs. We still have the problem of how to adequately represent the ORI/XRI Naming Environments. And if we contemplate the need to register a URI scheme or URN Namespace ID for the ORI Naming Environment we have already impacted on the Web without retaining a common approach to mapping names.
Summary and Recommendations
By rejecting any hybrid approach in mapping OpenURL resource identifiers to URIs we maintain the essential unity of the OpenURL Framework Naming Environments and also the identity of those Naming Environments.
On balance the two best approaches would seem to be:
· Method 1 –‘http:’
· Method 5 –‘open:’ (possibly prefigured by Method 4 –‘x-open:’)
The first has all the merits of familiarity and dereference capabilities and can be immediately deployed but has the demerits of appositeness of scheme. The second has the merit of exclusivity but the demerits of postponed deployment (possibly indefinitely) and lack of dereference capabilities. To allow immediate deployment the experimental ‘x-open:’ scheme could be used as a placeholder for a future registered ‘open:’ scheme.
A third way may be to consider the adoption of both mappings –‘http:’for dereference and ‘open:’ forcanonical reference. Semantic languages such as OWL could always be employed to assert equivalence between individual URIs, i.e.
<!—- OpenURL Framework ":ori:pmid:9036860" -->
<Open rdf:about="open:ori:pmid:9036860">
<owl:sameAs rdf:resource=”http://openurl.info/ori/pmid/9036860"/>
</Open>
One specific recommendation for OpenURL Framework resource identifiers is that they be ‘rooted’ by preceding the identifier with a colon (‘:’) so that there is no possibility of ever being mistaken for a URI, i.e. instead of
· ori:pmid:9036860
prefer
· :ori:pmid:9036860
